The multiplayer megapacket Twinsen Last month I joined KatherineOfSky's MMO event as a player. I noticed that after we reached a certain number of players, every few minutes a bunch of them got dropped. Luckily for you (but unluckily for me), I was one of the players who got disconnected every, single. time, even though I had a decent connection. So I took the matter personally and started looking into the problem. After 3 weeks of debugging, testing and fixing, the issue is finally fixed, but the journey there was not that easy. Multiplayer issues are very hard to track down. Usually they only happen under very specific network conditions, in very specific game conditions (in this case having more than 200 players). Even when you can reproduce the issue it's impossible to properly debug, since placing a breakpoint stops the game, messes up the timers and usually times out the connection. But through some perseverance and thanks to an awesome tool called clumsy, I managed to figure out what was happening. The short version is: Because of a bug and an incomplete implementation of the latency state simulation, a client would sometimes end up in a situation where it would send a network package of about 400 entity selection input actions in one tick (what we called 'the megapacket'). The server then not only has to correctly receive those input actions but also send them to everyone else. That quickly becomes a problem when you have 200 clients. It quickly saturates the server upload, causes packet loss and causes a cascade of re-requested packets. Delayed input actions then cause more clients to send megapackets, cascading even further. The lucky clients manage to recover, the others end up being dropped. The issue was quite fundamental and took 2 weeks to fix. It's quite technical so I'll explain in juicy technical details below. But what you need to know is that since Version 0.17.54 released yesterday, multiplayer will be more stable and latency hiding will be much less glitchy (less rubber banding and teleporting) when experiencing temporary connection problems. I also changed how latency hiding is handled in combat, hopefully making it look a bit smoother.

New Fluid system 2 (Dominik) Hi Factorians, Here is Dominik, with an update on the fluids. This time it is pretty much finished so I can tell you facts instead of just speculations. You will find how the new algorithm will work and some new handy usability features. In FFF-260 I wrote about how it all started, why we are doing it and what the plan is. There was a huge response from you all and I want to thank everyone for their contributions. Let me apologise to redditors, as at the beginning I started responding on the forums and when I realized there is reddit too, there were too many comments for me to handle. The forum users produced many ideas on how the system could work. About third of them was a fluid teleportation, many where known but many were entirely new and interesting. What intrigued me was the large variety of backgrounds they came from - differents kinds of engineers (mechanical, CS, electrical, ...), mathematicians, physicists, and even people with real pipes hands on experience. I won’t go through them here, you can find them on the forums or reddit. There were two proposals on the forum though that were so good that they made it into the game - from quinor and TheYeast. Both of these proposals were very similar and kinda similar to the previous game logic. What it shares is that the mechanic still uses fluid physics simulation and volume in a pipe as a base for the movement calculation. As a result, not much changes on the first glance. What they add though is an emphasis on the fluid network update being independent on the current state (i.e. updating one pipe only depends on state from the last tick) and is therefore independent on evaluation order, which was one of the big pains of the old model that led to sometimes ridiculous junction behavior. Difference between these two was rather small - quinor’s version allowed perfect throughput with 3 passes over the fluidboxes (fluidbox is the thing managing fluids for entities, so I will talk about them), while Yeast’s one was 2 pass with ¼ throughput. What was outstanding though is that TheYeast, a physicist, supported the model with a nice theoretical background and what’s more, he made an amazing JS simulator to test and compare various modification of the model. Because that extra pass in quinor’s version was too high a price for the perfect throughput, I went with TheYeast’s two pass one. Since the old algorithm only used a single pass run by entities for the update, I first needed to overhaul the whole system to allow accommodating the new one. Going from one pass to two passes necessarily means higher complexity, so we made a big effort to optimize everything we could to make sure we will still end up faster than 0.16. Kovarex wrote about it in FFF-271.

Hello, it is me, posila, with another technical article. Sorry.

Trains in blueprints Building trains again and again might be a daunting task. Especially when you start making a lot of mining outposts, artillery/supply trains with filtered cargo wagon slots etc. So I decided that we should extend blueprints to work with trains as well. The first condition was, that trains are only selected when you explicitly allow it in the checkbox, so they don't get in your way when building rail setups. Checking the button allows the train that was there to be put into the blueprint (similar to the way tiles work). For the sake of simplicity, we decided that once there is any rail in the blueprint, the train in it will be always buildable (as a ghost obviously), even if there are not rails to support the train at the moment. The train ghost will simply stay there and won't be buildable until rails are placed under it in a way so it can be placed. If I remove the rails from the blueprint, I get a second type of rail blueprint. In this case, all the parts of need to have rails to support it, this is mainly needed as without rails, there is no rail grid forced, so we should make sure, the train ghost won't be created in some wrong position. The small touch here is, that the blueprint also contains the schedule. With little-bit of improvisation, I can optimize the mine building a lot in the late game. I create a blueprint of mine train station. The stop will be called " Mine X". Both of the trains in the blueprint will have the " Mine X" -> " Smelting" schedule setup. Once I build the blueprint, I just rename the " Mine X" to whatever I want (" Mine 12" for example), and the train schedules are updated as well, so I'm almost ready to go. The last tweak I'm considering is to allow blueprints to contain the fuel insertion info similar to how they contain the module insertion info for assembling machines now.

Playtesting kovarex We have been playtesting a few days this week. There were some things we had to fix on the fly, but we still were able to play quite a lot, so I would say that it went surprisingly well. We have been able to get 3 multiplayer bases into a late game stage.

The release (kovarex) So we finally released the 0.17 experimental this week. (patch notes) Hooray :) Fun fact: The release script failed to post the release announcement on Steam and Reddit and we were wondering why. The reason is that the patch notes were so big, that it exceeded the maximum post size (40k characters). If this isn't the indication that we should split our releases into smaller chunks, than nothing is :). Code wise, it is clearly the biggest release, and the amount of bugs we have to go through correlates with it. In other words, there are tons of bugs of all variety. We want to fix everything eventually, but it will take time, so we had to prioritize this week to aim for the most generally playable version before the first weekend after release. That means mainly unloadable saves, unavoidable crashes, game failing on startup, and the most frequently occurring problems. Our automatic bug reporting system is helping us a lot with the last one. It is uncommon, but sometimes the automatically uploaded crash report doesn't have enough information for us to be able to fix the bug right away, but the number of times we see a crash happening is still extremely useful for prioritizing. When we see a crash on the forum, we can cross reference it to our automatic reports, and if is one of our 'top-hits', we know to investigate it right away. The most prominent crash related to loading specific kind of save happened with pipe ghosts happened more than 200 times. It was fixed (obviously), but lets wait and see what our top hit of 0.17.4 will be after the weekend. Overall this means, that bugs that are not critical, require design discussions or are not that simple to fix are not being dealt with right now. Also, we got quite a surprising cake gift today. It is extremely delicious and we are extremely thankful for it :).

Let me show you around. That's our lab table and this is our work-stool. And over there is our interplanetary space-platform! And here's where we keep assorted lengths of wire. Whoa! A real live space-platform! We designed it ourselves. Let us show you some of the different lengths of wire we used.

Hello, welcome once again to the world of facts.

Hello, Several FFFs ago we have shown you what a Space platform can look like (FFF-373), today we would like to explain how they work in a bit more detail.

Hello, Today we're going to take a look at a feature some of us have dreamt of changing for years now - the beacon transmission. The main purpose of beacons is to allow massively increasing your production in the late game while being more than just a module or a faster machine. To make use of beacons you need to adjust your building layout for them. Beacons succeed in this role, but...